1. Field of the Invention
The present invention relates to trading partner profiles that are used in conjunction with commercial translator software. More particularly, the present invention relates to a system and method for examining incoming data in order to build a trading partner profile for use with commercial translator software that supports data conversion from one format to another format based on information contained in a map.
2. Description of Related Art
Electronic Data Interchange (EDI) standards were developed to support computer-to-computer exchange of structured business documents (e.g., invoices, payment orders, price lists, requests for quotes, purchase orders, etc.) between an organization and its vendors, customers, or other trading partners. EDI standards dictate generally the structure and manner in which data is exchanged, but they do not dictate the specific data or file formats nor the communications protocols that the computers must use to exchange data. The standards are not strict so that they may satisfy many user needs. Consequently, there are many combinations of data elements, segments, and transactions that conform to the EDI standards so that a business can select a standard that is appropriate for its data processing environments. Examples of EDI standards include ASC ANSI X12, EDIFACT, TDCC, USC, VICS, EDX, ODETTE, and TRADACOMS. In order to exchange data (even data that does not conform to EDI standards), two businesses (i.e., trading partners) must agree on a format of communication. For example, the trading partners may agree the syntax and structure for data elements (individual data items such as dates, quantities, etc.), segments or records (groupings of elements for the purpose of defining part of a transaction), and transactions (groupings of segments). Regardless of which EDI standards or communication formats organizations support for the exchange of data with the external computer systems of their trading partners, most organizations"" internal data processing systems do not use data and file standards that conform to the EDI standards or other standard communication formats. Therefore, if an organization wants to accept or receive for further processing data and/or files that conform to various EDI standards, the incoming data may need to be translated or converted to a data or file format that is compatible with the organization""s internal data processing system (i.e., the business applications that process the incoming data or files). Translation or conversion of data may also be required if the organization wants to send data to a trading partner that accepts data only in conformance with a known or pre-defined file format.
To support the exchange of data conforming to EDI standards (or other known or pre-defined data formats), many businesses use a commercially available translator or converter program that translates or converts data from one format to another format. The translator relies on a map that tells it how to change the data from one format to another format. For example, one format may be an incoming ASC ANSI X12 transaction and the other format is an internal processing format that is needed for a particular business application. The map tells the translator how the incoming ASC ANSI X12 transaction should be processed for the business application. For the translator to operate correctly, entries are made in a set of tables to indicate what the incoming transaction is and what map should be used for the translation. The translator then locates the specific map that is required to complete the translation. The map may include information regarding the syntax and structure of the incoming data so that it can be converted to the appropriate output. Although translators are often used for processing of EDI transactions, they may be used for conversion of data that does not necessarily conform to EDI standards as long as the syntax and structure of the incoming data can be defined. The maps that the translator uses may be configured to translate any file of data in one format to another format.
If a business wants to accept or receive transactions from other entities or trading partners, each trading partner that will send data/files must have an entry in a table that provides the information needed by the translator to complete the conversion. An entry in a table for one incoming file of data is called a Trading Partner Profile. The trading partner profile is usually built manually by an individual who reviews the necessary information and creates an entry in a table. The trading partner profile structure is different for each translator so that the individual building the profile must know how to structure the data for the particular translator. The process is time-consuming and prone to errors.
Many businesses have a limited number of entities (usually 300 to 400, but possibly up to 3000) with which they will want to trade (i.e., exchange business documents). Most businesses have ongoing contractual relationship with their trading partners such that each trading partner generates many transactions during the term of the contract. Using manual techniques, it can take 20 to 30 minutes to build the trading partner profile and test an incoming file against the profile to ensure that the profile has been constructed properly. For 300 to 400 or even 3000 trading partners that generate many transactions, use of the manual trading profile building process is very manageable. The transaction costs for handling the transactions in most industries is high enough that the cost of building this information manually can be justified.
In some industries, however, the number of transactions from a trading partner may be very low. For example, in the healthcare industry, one trading partner may send only one transaction to a business such as a payer and not have an ongoing relationship. Handling the transaction on paper costs the receiving entity $0.50 to $1.50. The low paper cost does not justify the expense of building a trading partner profile for the single transaction. More importantly, businesses that typically process single or few transactions with one particular trading partner may have, in fact or potentially, many more trading partners than the 300-400 of the average business. For example, in the healthcare industry, many payers deal with 15,000 to 30,000 trading partners. In these cases, the manual processes of handling the paper transaction and building a trading partner profile are unmanageable and costly. Therefore, there is a need for an efficient and cost-effective method of creating a trading partner profile.
The present invention automates the process of building a trading partner profile for use with commercial translator software. The present invention is particularly well suited for use by businesses that have many trading partners submitting few transactions. The present invention is cost-effective in any environment that relies on trading partner profiles for processing of EDI-based transactions because the process of building a trading partner profile is fully automated. Information regarding each trading partner for a business is stored in a trading partner profiles database so that a translator in accordance with the trading partner profile may process incoming transactions. Each trading partner profile is comprised of a plurality of fields or parameters that the translator uses in processing files or transactions from a particular trading partner. The present invention therefore automatically determines the values of the fields or parameters that the translator uses for processing. Although the structure of a trading partner profile varies based on the translator used by the business, some basic information is common to virtually all translators.
The present invention is comprised of several software components that operate in accordance with data stored in files, lists, tables, databases, etc. to provide the features and functionality described herein. Although the present invention is described in terms of multiple software components and information stores, it is understood that the features and functionality of the present invention could be provided in accordance with fewer or more components and/or information stores. A Determine File Type component examines an inbound or incoming file to determine its type. A Build Trading Partner Profile component extracts information from the incoming file and a list of file type/map associations to build a trading partner profile that is stored in a trading partner profile database. A Perform Translation component then extracts information from the trading partner profile database to complete the translation of the incoming file to a format for use by business or other applications.
To use the present invention, a business that would like to accept or receive files from various trading partners defines a list of file types that it is willing to accept. The files may be EDI standard or non-EDI files. As long as the business and trading partner have agreed on a file format, any type of file may be processed by the present invention. For each file type that the organization has determined it will accept or receive, the name of a map for the file type and an instruction for calling the translator with the map is further specified in the list. The file type, map name, and instruction information is preferably stored in a table or database. Information in an incoming file drives the process of building the trading partner profile so that it does not have to be created manually. The incoming file is examined to determine its type. After the file type is determined, a trading partner identifier is extracted from the incoming file. The trading partner identifier, preferably, identifies the trading partner profile within the trading partner profile database. If a profile for the trading partner exists, it is used by the translator to complete the translation process. If a profile for the trading partner does not exist, it is built automatically as follows.
First, an entry in the trading partner profile database is created based on the trading partner identifier extracted or selected from the incoming file. Information regarding terminators and separators for the specific commercial translator in use by the business is added to the profile. The terminator and separator information typically is found in the incoming file and is located or selected based on the known or pre-defined structure of the file. Next, a map direction that identifies whether the transaction is inbound or outbound is located or selected and added to the profile. Also stored in the trading partner profile database is a production or test indicator that may be determined from the incoming file. Following completion of the trading partner profile, the translator completes translation of the incoming file based on information contained in the trading partner profile.